시스템 프로그래밍에서는 스핀락이라는 동기화 기법이 있다. 스핀락은 락 중에 가장 원시적인 락이고 요약하면 다음처럼 구현한다.
while(!탈출조건) { nop; }
문제는 이 락이 CPU를 소모한다는 것이다. CPU를 다 쓰고 조건을 검사하며 대기한다. 요즘은 멀티코어가 기본이라 위험성은 상대적으로 적어졌으나 여전히 CPU를 뽑아먹는다. 위험성이 적어졌다는 뜻을 좀 더 상세히 쓰면 싱글코어에서 스핀락은 시스템을 중단시킬 수도 있다. 선점형 OS가 이런저런 컨텍스트 스위칭 사정으로 자원을 강제로 빼앗을 수는 있지만 쉘과 원격 터미널이 모두 잠길 가능성이 높다. 멀티코어에서는 CPU 1개만 잡아먹는다. 물론 (...어쩌고 저쩌고 생략)
그래서 다양한 동기화 락 기법을 사용하는데 이것은 컨텍스트 스위칭을 유발하고, 동기화 무결성을 보장하기 위해 이렇고 저렇고 할 일이 많다. (일부 경량 쓰레드 파이버등의 기법은 논외로) 성능 저하도 문제지만 복잡한 것이 더 문제다. 언어나 시스템에 따라 글로벌 락으로 퉁치는 시절도 있었다. 코딩은 편하지만 느리다.
그래서 어떤 도메인에서는 스핀락이 금기의 영역이다. 아니 사실 대부분은 그렇다.
그런데,
스핀락의 대기 시간이 극한으로 짧다고 보장한다면, 스핀락이 월등히 빠르고 간결하다. 컨텍스트 스위칭이 일어나지 않으며, 즉각적으로 응답한다. 여기서 극한은 상대적이고 모호한 개념이며 요즘의 OS에서 그 수치를 가늠하기 쉽지는 않으므로 따로 적지는 않겠다. (선호하는 범위는 있으나 문자로 적으면 털리기 때문에)
예를 들어 터치스크린을 CPU와 인터럽트로 제어하던 시절이 있었다. 이때 드라이버가 다양한 인터럽트 대기와 스케쥴링을 허용하면 펜슬 드래그 드로잉에서 백발백중 튄다. 부드러운 곡선이 쫓아오지 못한다. 베이지안 보정 같은 꼼수는 꼼수라서 사용성이 꽝이다. 이 때는 스핀락과 인터럽트, 스케쥴링을 적절히 통제해야한다. (생략) 10년전부터 전용 IC로 해결하기 시작했는데 요즘은 AP에 통합했는지 모르겠다.
인터넷 세계의 코딩에서는 다양한 비동기 기법이 있다. 응답 속도 대비 처리 속도가 쫓아오지 못하기 때문에 발생하는 일이 많다. 프로그래머는 Fire and Forgot(전투기의 미사일 발사 개념 중 하나)을 원하는데 응답을 대기하라니 귀찮은 일이다. 비동기로 해결 할 수 있다. 비동기로 해결을 하다보니 구조가 복잡하다.
데이터 세계도 마찬가지다. 입력 - 처리 - 출력하면 되는데 처리 속도가 못 쫓아온다. 그래서 증분처리가 있고, 미결에 대한 보완 처리, 서로 다른 인터벌 배치의 오버랩 처리, 마트 구성, DW 처리 어쩌고저쩌고 하다보니 쫑나고 빵꾸나고 앞 뒤 바뀌고 실패한 것, 성공한 것, 실패 대응한 것, 실패 대응도 실패한 것, 다 모았는데 잘 모았는지 확인, 가처분 영역에서 실사용 영역으로 덤핑, 여기저기 모인 중간 쓰레기 정리 등의 업무가 발생한다.
잘하면 된다. 나는 잘 못하지만.
그런데,
한 편으로 처리 속도를 극한으로 올리면 복잡한 일들이 간결해진다. 입력 -> 처어어어어어.........리 -> 출력. 이 문제라서 만든 구조이므로, 입력 -> 칰 -> 출력으로 바꾸는 궁리를 해 볼 수 있다.
스핀락이다.
어 이거 여기를 10배 100배 빠르게 하면 저어어어어어어기서부터----->여기까지 다 뺄 수 있겠는데요? 그러면 비용이 10배 100배가 아니라 1000배 줄 것 같은데요?
...라는 지점들이 가끔 있다. 물론 나는 그럴 때 더 이상의 발언을 하고 싶지만, (생략)